Communications networks (e.g., the Internet) continue to have a growing role in today's world. As used herein, a “network” or a communications network” is a group of two or more devices interconnected by one or more segments of transmission media on which communications may be exchanged between the devices. Each segment may be any of a plurality of types of transmission media, including one or more electrical or optical wires or cables made of metal and/or optical fiber, electromagnetic (e.g., wireless) transmission or any combination of these transmission media. As used herein, “plurality” means two or more. As used herein, a “network device” is a device operative to communicate on a network, including, but not limited to: workstations, personal computers, terminals, laptop computers, end stations, servers, gateways, registers, switches, routers, hubs, bridges, directories, transmitters, receivers, repeaters, and any combinations thereof. As used herein, whether in the written description or the claims, the terms “comprising”, “including”, “carrying”, “having”, “containing”, “involving”, and the like are to be understood to be open-ended, i.e., to mean including but not limited to. Only the transitional phrases “consisting of” and “consisting essentially of”, respectively, shall be closed or semi-closed transitional phrases, as set forth, with respect to claims, in the United States Patent and Trademark Office Manual of Patent Examining Procedures (Original Eighth Edition, August 2001), Section 2111.03.
As the roles of networks continue to expand, network security becomes increasingly critical. A common form of network security is user authentication, in which users must authenticate their identities to a network before being allowed access to the network or certain network resources available on the network. As used herein, an “authentication protocol” is a protocol (i.e., a set of rules and procedures) for authenticating a user to a network. A common form of user authentication is password-based authentication, in which an authentication server issues a challenge to the user (e.g., prompts the user for user credentials), and the user responds with user-authenticating information (e.g., credentials such as a username and password). Typically, the user-authenticating information as supplied by the user is encrypted. As used herein, an “authentication server” is a logical entity residing on a network device, which is operative to authenticate a user for access to a network. As used herein, a “challenge” is information transmitted from a first network device to a second network device, as part of an authentication process, prompting the second network device to issue a response (e.g., including one or more user credentials) to be authenticated.
Most password-based authentication protocols are inherently of low security due to the fact that passwords are typically of low entropy. Such protocols are susceptible to “dictionary” (i.e., password-guessing) attacks mounted by an eavesdropping attacker. Such password-based authentication protocols include Challenge Handshake Authentication Protocol (CHAP), Extensible Authentication Protocol-Message Digest 5 Challenge (EAP-MD 5 Challenge or MDC), Microsoft's MS CHAP and EAP-GenericTokenCard. Other authentication protocols use more secure encryption techniques that involve the use of encryption keys. Such authentication protocols include Extensible Authentication Protocol GSM Subscriber Identity Module (SIM).
To further secure communications between two network devices, tunneling protocols have been developed. As used herein, a network “tunnel” is a secure transmission path established across one or more networks between a first network device and a second network device, such that the first and second network devices can exchange communications along the path, and the contents thereof (except for information necessary for proper switching and routing) is secured against ascertainment by any entity except the first and second network devices. “Tunneling” refers to the establishing and maintaining of a tunnel, and the transmission of communications within a tunnel. A “tunneling protocol” is a protocol for implementing a tunnel. A common example of the use of a tunnel is to establish a Virtual Private Network (VPN) across a public network (e.g., the Internet) between a user device and a remote access server, for example, a Remote Authentication Dial-In User Service (RADIUS) server, of a private network such as a corporate Local Area Network (LAN).
Tunneling protocols use more sophisticated encryption techniques and typically use public/private key cryptography to establish encryption keys that allow subsequent transmissions to be secure against eavesdroppers Typically, at least one of the network devices that terminate (i.e., serve as an endpoint for) the tunnel certifies its identity to the other network device using a certificate or other credentials; both devices may separately authenticate. After the identities of one or both of the network devices is certified (such that each certified device is “trusted” by the other device), the tunnel is created and secure communications are exchanged within the tunnel between the two network devices. There are a variety of tunneling protocols, including Extensible Authentication Protocol Tunnel Transport Layer Security (EAP-TTLS or TTLS) and Extensible Authentication Protocol-Protected Extensible Authentication Protocol (EAP-PEAP or PEAP). TTLS and PEAP both are based on tunnels created via Transport Layer Security (TLS) technology, which was formerly known as Secure Sockets Layer (SSL). An authentication protocol may be encapsulated within a tunnel established by a tunneling protocol, in order to secure the authentication protocol against eavesdropping attacks. As used herein, an “inner protocol” or “tunneled protocol” means an authentication protocol transmitting and/or receiving communications within a tunnel provided by a tunneling protocol.
FIG. 1 is a block and information flow diagram illustrating an example of a known system 100 for encapsulating inner protocol communications within a tunnel provided by a tunneling protocol. System 100 includes client 102 and tunnel server 112.
As used herein, a “client” is a logical entity associated with a user, residing on a network device, serving as an endpoint to a tunnel and operative to generate and transmit a response to a challenge on behalf of the user. The network device on which the client resides may be used by the user to access a network, for example, by communicating with a remote access server of the network. The network device on which the client resides may be a user device, for example, a workstation, terminal, personal computer, laptop computer, telephone, pager, BlackBerry™ brand device, personal digital assistant (PDA), or any combination thereof or other device that can provide client functionality. As used herein, a “tunnel server” is a logical entity, residing on a network device different than the network device on which the client resides, serving as an endpoint to a tunnel and operative to generate and transmit a challenge.
Tunnel server 112 issues a challenge 108 in accordance with an inner protocol to client 102. In response, a hash generator 104 of client 102 generates a response 110 to the challenge and the client transmits the response 110 to tunnel server 112. Tunnel server 112 and client 102 serve as endpoints (i.e., terminals) for a tunnel 106 that encapsulates communications (e.g., challenge 108 and response 110) between the client 102 and tunnel server 112. The inner protocol may be any suitable protocol such as (but not limited to) any of a variety of legacy authentication protocols, for example, an MD5-based authentication protocol, such as CHAP or MDC. As used herein, a “MD5-based protocol” is an authentication protocol that uses an MD5 algorithm or variation thereof to exchange information, and an MD5-based hash function is an MD5 hash function or variant thereof.
FIG. 2 is a flowchart illustrating an example of a known method 200 of authenticating a user according to an MD5 algorithm.
In Act 202, an MD5 challenge is generated for the user. Such challenge may be generated on an authentication server (e.g., 126) or on an intermediate server, for example, a tunnel server (e.g., 112) between the client (e.g., 102) and authentication server. Such challenge may be a random challenge of variable length.
In Act 204, a first communication is transmitted to the client, the first communication including the MD5 challenge. Such communication may be transmitted directly from the authentication server or through an intermediate server.
In a following Act 206, the following information is concatenated in the following order: the MD5 authentication protocol identifier, the user's password, the MD5 challenge, a single octet of hexadecimal value 80, padding octets and eights octets indicating a message length to produce an MD5 hash function input sequence. The number of padding octets is configured such that the length of the MD5 hash function input sequence is a multiple of 64 octets. The “message” is the concatenation of the authentication protocol identifier, the user's password and the MD5 challenge, such that the message length indicates the length of this concatenation.
In Act 208, an MD5 hash value (i.e., message digest or hash) is generated using MD5 hash function input sequence, for example, as illustrated in FIG. 3. A hash value is a number generated from a string of information (e.g., text, a number, or a combination thereof). Typically, a hash value is substantially smaller than the string of information from which it was generated. Hash functions (e.g., an MD5 hash function) are designed such that it is extremely unlikely that any two strings of information (i.e., the hash function input sequence) input to the hash function produce the same hash value.
FIG. 3 is an information flow diagram illustrating a known method of generating an MD5 hash value 318 from an MD5 hash function input sequence 302. The hash function input sequence 302 includes the message 310 and the appendage 317. The message 310 includes the MD5 protocol identifier 304, user's password 306 and MD5 challenge 308. The appendage includes hex 80 octet 312, padding octets 314 and eight-octet message length field 316. The value of message length field 316 indicates the length of message 310.
The MD5 hash function input sequence 302 is input to the hash generator 104 to produce MD5 hash value 318. The elements of input sequence 302, namely components 304, 306, 308, 312, 314 and 316 are received by the hash generator in the order shown in FIG. 3, starting with 304 and proceeding in ascending order.
MD5 is an iterative algorithm that applies a hash function repeatedly to successive 64-octet blocks of input sequence data until the entire input sequence has been hashed. The message included within the input sequence may be of any length, and the MD5 appendage is configured such that the total input sequence length is a multiple of 64 octets. Each iteration of the MD5 algorithm applies the hash function to two parameters: a 16-octet vector, and a 64-octet segment from the input sequence. If f (x,y) is the hash function, V [n] is an nth 16-octet vector, and M [n] is an nth 64-octet message block, than V(0)=I, which is a fixed initialization vector defined for MD5, and V [n+1]=f (V [n], M [n]). The final output of the MD5 algorithm is a 16-octet vector defined as V(N), where N is the number of 64-octet blocks included in the function input sequence. Accordingly, referring to FIG. 3, MD5 hash value 318 is a 16-octet vector, V(N).
Returning to FIG. 2, in Act 210, a second communication is transmitted from the client to the tunnel server, the second communication including the generated MD5 hash value in response to the challenge, for example, MD5 hash value 318. In a final Act 212 of method 200, the user is authenticated based on the MD5 hash value, for example, by an authentication server.
Recent cryptographic analysis has revealed that, while tunneling protocols generally provide more secure communications across a network than authentication protocols, they introduce a new vulnerability in certain circumstances. Because these tunneling protocols do not cryptographically combine their encryption keys with encryption keys derived from the inner protocols that they encapsulate, it is possible for an attacker to effect the following attack, called a Man-in-the-Middle (MiM) attack. The attacker poses as an authentication server and dupes a client to use a password-based authentication protocol outside of a tunnel (i.e., in untunneled mode) to exchange protocol payloads with the attacker. Then, posing as the client, the attacker establishes communication with a tunnel server and establishes a tunnel. In response to the tunnel server's challenge, the client responds with a protocol payload (e.g., the response) gained from the client. The transmission of the protocol payload is encapsulated within the tunnel. Thus, the attacker authenticates to the server as if the attacker were the actual user. In order for such a MiM attack to be feasible, the following conditions must be met: (1) the user must use the same legacy authentication protocol both in tunneled and untunneled modes, (2) the user must use the same credentials (e.g., username and password) in both tunneled and untunneled modes, and (3) the attacker must be able to pose as an authentication server on the network on which the user uses the legacy protocol in untunneled mode.
Referring to FIG. 1, consider the example when the client 102 attempts to establish a session with an authentication server 126 across a wireless communication medium. The attacker 118 poses as the authentication server 126 and intercepts communications from the client 102. The attacker then issues a challenge 114 to the client in accordance with a legacy authentication protocol and outside of a tunnel (i.e., in untunneled mode), and the client 102 responds, outside of a tunnel, with a response 116 in accordance with the legacy authentication protocol. The attacker 118 records the response 116. The attacker 118 then initiates a session with another server using the same legacy authentication protocol, but inside of a tunnel. For example, attacker 118 initiates a session with tunnel server 112 or another server for which tunnel server 112 serves as an intermediate server for communication with attacker 118. In either event, the tunnel server 112 and the attacker 118 serve as terminals or endpoints for a tunnel 120. If the client 102 is configured to use the same legacy authentication protocol and use the same credentials within tunnel 120 as were used to generate response 116 outside of the tunnel 120, then, in response to challenge 124 (which is the same as challenge 114, albeit encapsulated within tunnel 120), attacker 118 responds with response 122 (which is the same as response 116, albeit encapsulated in tunnel 120). The tunnel server 112 or the authentication server then authenticates the user credentials within the response 122 and confirms that attacker 118 is client 102, allowing great mischief to follow.
The Internet Engineering Task Force (IETF) EAP working group is studying means to preclude the MiM attack. The current general opinion of that group is that the MiM attack only can be prevented if the inner protocol is capable of generating its own encryption keys. This opinion implies that tunneling protocols such as TTLS and PEAP can be made safe against the MiM attack for inner protocols that can generate encryption keys such as MS CHAP and SIM, but not for inner protocols such as CHAP, MDC or GenericTokenCard.